Bug 253747 - SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "write" to / (device_t).
SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "write" to / (device_t).
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: smartmontools (Show other bugs)
7
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-21 13:51 EDT by Mark Harig
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-24 07:07:38 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 Mark Harig 2007-08-21 13:51:33 EDT
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 2.6.22.1-41.fc7 #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 04:40:14 EDT
Nothing like this happened on FC-6... Maybe this has to do something with
selinux-policy.
Comment 2 Mark Harig 2007-08-23 11:13:00 EDT
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 11:56:31 EDT
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.