Bug 675065 - SELinux is preventing /usr/sbin/smartd from 'create' accesses on the chr_file twe0.
Summary: SELinux is preventing /usr/sbin/smartd from 'create' accesses on the chr_file...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:f283fe3e4f2...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-04 06:31 UTC by Mark Harig
Modified: 2011-03-24 03:24 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.9.7-37.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-22 18:52:01 UTC
Type: ---


Attachments (Terms of Use)

Description Mark Harig 2011-02-04 06:31:12 UTC
SELinux is preventing /usr/sbin/smartd from 'create' accesses on the chr_file twe0.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that smartd should be allowed create access on the twe0 chr_file 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 smartd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:system_r:fsdaemon_t:s0
Target Context                system_u:object_r:fixed_disk_device_t:s0
Target Objects                twe0 [ chr_file ]
Source                        smartd
Source Path                   /usr/sbin/smartd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           smartmontools-5.40-3.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-28.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.10-74.fc14.x86_64
                              #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64
Alert Count                   10
First Seen                    Fri 04 Feb 2011 12:34:00 AM EST
Last Seen                     Fri 04 Feb 2011 01:21:19 AM EST
Local ID                      dde04082-981e-4943-ba9a-390f8b5077a7

Raw Audit Messages
type=AVC msg=audit(1296800479.938:25629): avc:  denied  { create } for  pid=5333 comm="smartd" name="twe0" scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1296800479.938:25629): arch=x86_64 syscall=mknod success=no exit=EACCES a0=7fff59ea1c90 a1=2180 a2=f900 a3=7f8155e741e0 items=0 ppid=5332 pid=5333 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=6 comm=smartd exe=/usr/sbin/smartd subj=unconfined_u:system_r:fsdaemon_t:s0 key=(null)

Hash: smartd,fsdaemon_t,fixed_disk_device_t,chr_file,create

audit2allow

#============= fsdaemon_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow fsdaemon_t fixed_disk_device_t:chr_file create;

audit2allow -R

#============= fsdaemon_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow fsdaemon_t fixed_disk_device_t:chr_file create;

Comment 1 Mark Harig 2011-02-04 06:36:07 UTC
Following the SELinux Alert Browser's instructions:

  $ sudo grep smartd /var/log/audit/audit.log | audit2allow -M mypol
  $ sudo semodule -i mypol.pp

and then rebooting and logging in, the error seen above is no longer occurring.

  $ sudo semodule -l | grep mypol
  mypol  1.0

Comment 2 Mark Harig 2011-02-04 06:41:11 UTC
Messages from "smartd" in /var/log/messages:

smartd[2478]: smartd 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)#012Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net#012

smartd[2478]: Opened configuration file /etc/smartd.conf
smartd[2478]: Configuration file /etc/smartd.conf parsed.
smartd[2478]: Device: /dev/twe0 [3ware_disk_00], opened
smartd[2478]: Device: /dev/twe0 [3ware_disk_00], found in smartd database.
smartd[2478]: Device: /dev/twe0 [3ware_disk_00], enabled SMART Attribute Autosave.
smartd[2478]: Device: /dev/twe0 [3ware_disk_00], enabled SMART Automatic Offline Testing.
smartd[2478]: Device: /dev/twe0 [3ware_disk_00], is SMART capable. Adding to "monitor" list.
smartd[2478]: Device: /dev/twe0 [3ware_disk_01], opened
smartd[2478]: Device: /dev/twe0 [3ware_disk_01], found in smartd database.
smartd[2478]: Device: /dev/twe0 [3ware_disk_01], enabled SMART Attribute Autosave.
smartd[2478]: Device: /dev/twe0 [3ware_disk_01], enabled SMART Automatic Offline Testing.
smartd[2478]: Device: /dev/twe0 [3ware_disk_01], is SMART capable. Adding to "monitor" list.
smartd[2478]: Monitoring 2 ATA and 0 SCSI devices
smartd[2480]: smartd has fork()ed into background mode. New PID=2480.

Comment 3 Mark Harig 2011-02-04 06:42:44 UTC
Also, note that this is using selinux-policy-3.9.7-28 from the 'updates-testing' repository.

Comment 4 Daniel Walsh 2011-02-04 15:08:24 UTC
Miroslav lets add

storage_create_fixed_disk_dev(fsdaemon_t)

to F13/F14

Mark, you can create a custom policy module

policy_module(mysmartd, 1.0)
gen_require(`
type fsdaemon_t;
')
storage_create_fixed_disk_dev(fsdaemon_t)


Then compile and install it.

# make -f /usr/share/selinux/devel/Makefile
# semodule -i mysmartd.pp

Comment 5 Mark Harig 2011-03-01 02:22:21 UTC
I installed the latest selinux-policy update today and un-installed the local policy that I had installed, as described in Comment 1, above.

$ rpm -q selinux-policy
selinux-policy-3.9.7-31.fc14.noarch

$ sudo semodule -l |grep mypol
mypol	1.0	

$ sudo semodule -r mypol

I rebooted the operating system and checked /var/log/messages for smartd.  The error described above still appears.

Does this mean that the policy change has not yet been included in selinux-policy?

Here are the contents of mypol.te:

module mypol 1.0;

require {
	type fsdaemon_t;
	type fixed_disk_device_t;
	class chr_file create;
}

#============= fsdaemon_t ==============
allow fsdaemon_t fixed_disk_device_t:chr_file create;

Comment 6 Mark Harig 2011-03-01 02:36:29 UTC
I re-installed the local policy (listed in Comment 5) and rebooted.  The smartmontools service no longer reports the errors that were originally reported.

Since this report is marked as closed, is it known what 'selinux-policy' update I can expect the fix to be available for testing?

Comment 7 Miroslav Grepl 2011-03-01 09:52:09 UTC
I have found a bug. Please keep your local policy for now. Thank you.

Comment 8 Mark Harig 2011-03-01 17:22:30 UTC
(In reply to comment #7)
> I have found a bug. Please keep your local policy for now. Thank you.

OK.  Please let me know when you have a fix in the test area.  I will then install it and let you know what I find.

Thank you.

Comment 9 Miroslav Grepl 2011-03-09 15:45:55 UTC
You can use the latest F14 selinux-policy which is available from koji for now

http://koji.fedoraproject.org/koji/buildinfo?buildID=231998

Comment 10 Fedora Update System 2011-03-18 15:06:59 UTC
selinux-policy-3.9.7-34.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-34.fc14

Comment 11 Fedora Update System 2011-03-21 08:44:59 UTC
selinux-policy-3.9.7-37.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-37.fc14

Comment 12 Fedora Update System 2011-03-22 18:50:33 UTC
selinux-policy-3.9.7-37.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Mark Harig 2011-03-24 03:24:01 UTC
(In reply to comment #12)
> selinux-policy-3.9.7-37.fc14 has been pushed to the Fedora 14 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

After un-installing my local policy, updating to selinux-policy 3.9.7-37, and rebooting, the smartd service was able to start as expected (and special device files /dev/twe[0-15] were created).

Thank you!


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