Bug 253747 - SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "write" to / (device_t).
Summary: SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "write" to / (device_t).
Alias: None
Product: Fedora
Classification: Fedora
Component: smartmontools   
(Show other bugs)
Version: 7
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tomas Smetana
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-21 17:51 UTC by Mark Harig
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-24 11:07:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mark Harig 2007-08-21 17:51:33 UTC
Description of problem:

SELinux denied access requested by /usr/sbin/smartd. It is not expected that
this access is required by /usr/sbin/smartd 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.
Version-Release number of selected component (if applicable):

How reproducible:

Every time I restart the 'smartd' service
Each time I issue the command (as 'root'): # /sbin/service smartd restart

Steps to Reproduce:
1. Log on as 'root'.
2. Start a terminal window.
3. Issue the following command at the shell prompt:
      /sbin/service smartd restart
Actual results:
The setroubleshoot browser displays an alert.  When I start that browser, it
displays the summary and description that I have included above.

Expected results:
The smartd service should restart without causing the setroubleshoot browser to
issue an alert.

Additional info:

Source Context:   system_u:system_r:fsdaemon_t
Target Context:   system_u:object_r:device_t
Target Objects:   / [ dir ]
Affected RPM:     smartmontools-5.37-3.fc7[application]filesystem-2.4.6-1.fc7
Packages:         [target]
Policy RPM:       selinux-policy-2.6.4-33.fc7
Selinux Enabled:  True
Policy Type:      targeted
MLS Enabled:      True
Enforcing Mode:   Enforcing
Plugin Name:      plugins.catchall_file
Host Name:        localhost
Platform:         Linux localhost #1 SMP Fri Jul 27 18:21:43 EDT
2007 x86_64 x86_64
Alert Count:      12
First Seen:       Wed 15 Aug 2007 05:51:24 PM EDT
Last Seen:        Sun 19 Aug 2007 08:13:18 PM EDT
Local ID:         e4bded9f-0bca-4770-9655-1e731bafce25
Line Numbers:  

Raw Audit Messages :

avc: denied { write } for comm="smartd" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/smartd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="/" pid=2726
scontext=system_u:system_r:fsdaemon_t:s0 sgid=0
subj=system_u:system_r:fsdaemon_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0

Comment 1 Tomas Smetana 2007-08-23 08:40:14 UTC
Nothing like this happened on FC-6... Maybe this has to do something with

Comment 2 Mark Harig 2007-08-23 15:13:00 UTC
The summary line provided by SELinux says that smartd attempted to write to '/'
(the root directory).  Is this expected and required behavior by smartd?  Or
should smartd only be writing to log files?  Or is SELinux mistaken in reporting
that smartd is attempting write to '/'?  (Running 'strace' on 'smartd' on a
system without SELinux should help to answer the last question.)

Comment 3 Mark Harig 2007-08-23 15:56:31 UTC
On further investigation, I would like for this report to be set to closed.  I
was reporting a problem that is no longer being reported by SELinux.  The
problem had be reported up until 19 Aug.  It was a problem with the
configuration of smartd.  I will be replacing this Bugzilla report with a
different one that is related to the interaction between SELinux and smartmontools.

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